完成品質掃描與測試後，下一個關鍵問題是：我們該如何將程式碼交付給用戶？這就是 CD（持續交付/持續部署）的核心命題。在進入具體的部署腳本之前，我們必須先建立正確的戰略觀點：環境晉升 (Environment Promotion) 與 不可變產出物 (Immutable Artifacts)。

環境晉升 (Environment Promotion)

在專業的開發流程中，我們通常會經歷多個環境：

1. Dev (開發環境)：開發者頻繁提交與測試。
2. Test/Staging (測試/預發布環境)：模擬生產環境，進行 QA 測試與配置驗證。
3. Prod (生產環境)：最終面對用戶的環境。

核心原則：我們不應該在每個環境都「重新編譯」一次原始碼。相反，我們應該在 CI 階段只編譯一次，產生一個產出物，然後讓這個產出物「晉升」到不同的環境。這能確保我們在不同環境測試的是完全相同的程式碼邏輯。

不可變產出物 (Immutable Artifacts)

為什麼「一次編譯，到處部署」如此重要？

• 消除不確定性：如果在 Test 環境測試的二進位檔與 Prod 環境的不同，測試就失去了意義。
• 快速回滾 (Rollback)：如果生產環境出問題，我們可以快速重新部署上一個「已知良善」的版本，而不需要重新跑一遍編譯與打包流程。
• 追溯性：每個產出物都應該與特定的 Git Commit Hash 綁定。

挑戰：配置管理 (Configuration Management)

如果產出物（如 .dll, .exe 或容器鏡像）是不可變的，那不同環境的差異（如資料庫連線字串、API Key）該如何處理？

這就是 配置與邏輯分離 的重要性。常見的策略有：

1. 環境變數注入：運行時讀取 OS 環境變數。
2. 配置渲染 (Configuration Rendering)：在部署前，根據模板與各環境的秘密中心（Vault）動態產生設定檔（如 appsettings.json）。

CD workflow 的設計思路

在本系列接下來的實作中，我們將採用一個特殊的架構來克服組織內網限制：

1. 外部協調器：GitHub Actions 作為流程觸發與狀態回傳中心。
2. 安全性代理：GitLab 作為中間代理程式（Proxy），接收來自 GitHub 的變更並同步回內網。
3. 內部執行器：位於內網的 Jenkins 伺服器偵測到 GitLab 異動後，執行編譯、渲染與部署動作。

具體流程如下：

1. Build：在 Jenkins Agent 編譯專案，並標記版本。
2. Render：使用 Python 腳本從 Vault 抓取環境專屬參數，填充入配置模板。
3. Package：將二進位檔與渲染後的設定檔打包成 Zip。
4. Transfer：透過 SCP 將 Zip 派送到目標 Windows 伺服器 (<INTERNAL_IP>)。
5. Trigger：遠端透過 SSH 觸發部署任務。

總結

CD 是一套關於「信任」的機制。透過環境晉升與不可變產出物，我們建立了對發布流程的信心。

明天，我們將回到 Jenkins Shared Library，看看如何設計一套具備靈活配置能力的 CD 共享庫，以應對 AI 生成的大量專案需求。